Hi, thanks for starting this!

Rust 1.88 is less than a year old, I'm cautious to publish with that MSRV.

Letting CI run on it, now.

Rust 1.88 is less than a year old, I'm cautious to publish with that MSRV.

The MSRV requirement comes from WGPU itself. So I'm not sure if there's much we can do about that. Is there a reason for wanting such a conservative MSRV? I know there are domains where this is really important, but most of the games/UI ecosystem I'm familiar with seems to be quick to update rustc versions.

I'll see if I can fix up the rest of the examples.

Is there a reason for wanting such a conservative MSRV? I know there are domains where this is really important, but most of the games/UI ecosystem I'm familiar with seems to be quick to update rustc versions.

Some people are still managing their Rust installations through distro package managers. :(

I'll see if I can fix up the rest of the examples.

Sounds good. I have been looking forward to pinning the examples to a published version of pixels to allow them to diverge.

@parasyte This should all be working now.

Some people are still managing their Rust installations through distro package managers. :(

Can we just suggest that such users use an older version of pixels? I suppose in an ideal world we'd have a pixels crate version for every version of wgpu and then people can just pick the version that matches their preferred MSRV / WGPU version. Obviously this hasn't happened historically, but perhaps it could happen going forwards.

90% of the work of updating this PR was updating the examples (and most of that was due to Winit rather than wgpu). So if we could let the examples run against published versions as you suggest then it shouldn't be too much work to keep the main pixels crate updated.

Can we just suggest that such users use an older version of pixels?

Certainly! I'm just explaining the reason for exercising caution, as you asked.

90% of the work of updating this PR was updating the examples (and most of that was due to Winit rather than wgpu). So if we could let the examples run against published versions as you suggest then it shouldn't be too much work to keep the main pixels crate updated.

Yeah, that's the situation. The examples almost certainly have to go in that direction, because synchronizing multiple interdependent dependencies maintained by different groups has proven challenging. I've expressed interest in doing this myself a few times in this issue tracker.

Eventually, I might move all examples except minimal-winit out of the repo. The lockfile is going to grow quite a bit with duplicates. And in some cases, dependencies may be unresolveable (cargo's "failed to select a version" problem).

Feel free to simplify examples to pinning pixels to a published version. And maybe note in the example's README which version is used so people are not caught off guard when they copy its code.

Certainly! I'm just explaining the reason for exercising caution, as you asked.

Gotcha!

Eventually, I might move all examples except minimal-winit out of the repo.

That might make sense. There is also potential to merge some of the examples think (it would likely be possible to implement one example that does web, android and desktop platforms, and rendering with tiny-skia isn't really any different to rendering with raqote)

Feel free to simplify examples to pinning pixels to a published version.

I think I have them all running with the version of pixels in this PR (helps that winit 0.30 has been out for ages, so basically everything has updated to that). So I figure we can have them all up to date as a baseline and then see where we're at next time we come to do an update.

@clearlysid Any chance of a crates.io release with this update?